A few weeks ago, I ve added support for Remote, Apple s iPhone application for controlling iTunes remotely. Here, support means Remote can be paired with forked-daapd and can be used to browse the library. And that s it, for now. At this point, there won t be much visible activity on forked-daapd for some time. I m working on a couple of things, but they take time and they require a lot of new code. So, for a couple weeks now, I ve been working on that. I have some code outside forked-daapd that is starting to work well, but it s not there yet, far from it. Then it ll have to be integrated into forked-daapd, which means a lot of new code there too. Bug fixes will still happen in the meantime, and some smaller new features may also appear before the Big Thing . So if you find or encounter bugs, feel free to report them still. If you have patches or ideas you want to discuss, feel free too. As I wrote to a couple people by mail already, good things come to those who wait or contribute. With all that, I ve updated the Debian packages, given that there won t be important changes for a while; I hope they re useful to some of you out there. Note that I m making an amd64 binary package available alongside the source package; it s built on a current Debian unstable system, but if that s not suitable for you, in terms of dependencies or architecture, you can trivially build a suitable binary package from the source package. As a reminder, I have packages of the ANTLRv3 C runtime too. I ve also added antlr-3.1.3.jar there, in case you need it and can t find it at the upstream download site.

Ten years ago, pretty much to the day, I was installing my first Debian system, a frozen Potato, using a release-candidate version of the boot-floppies. A few days later, I was reading the Policy, New Maintainer s Guide and Developer s Reference while building my first package. It s been a fun ten years, with ups and downs, and I m looking forward to what s coming next.

Mostly an update to my previous post on the subject, I ve just completed the FreeBSD port. It also builds and runs on GNU/kFreeBSD, by the way. The filescanner for forked-daapd on FreeBSD is now up to par with its Linux counterpart, as much as possible. Contrary to the latter, it will lose some metadata (play count, for instance) when files get moved around, because it s not possible to track moves and renames accurately. It also performs more rescans than the Linux/inotify implementation. Still, it works just as good. On a related note, the machine I tried to install FreeBSD 8.0 on and finally ended up installing GNU/kFreeBSD on just seemingly committed suicide. I m not sure what message it s trying to send me. It s previously been my main workstation for the best part of 10 years, so this is a bit sad. At least I found some bugs in the process and fixed some too:

• 2 bugs in forked-daapd, one of them a crasher,
• a bug in Avahi on kFreeBSD,
• a bug in GRUB2 as used on the kFreeBSD daily d-i images.

Not bad, is it?

Since I released forked-daapd, I ve got a couple of emails about porting it to FreeBSD. Apart from isolating and reimplementing the parts of the code using signalfd and inotify, there isn t much work to do beside taking care of the usual libc/platform issues. However, when you don t know the codebase and don t know the APIs you re replacing, it makes it a bigger job. So, I ve just spent a day going through FreeBSD documentation, installing FreeBSD 8.0 in qemu (because it wouldn t install on my spare machine due to a bootloader issue that s at least 5 years old ), and started porting the codebase. A dozen or so commits later, forked-daapd builds and runs on FreeBSD. With one caveat: the filescanner doesn t update the database on the fly when the library directory is modified. While I ve put in support for kqueue/kevent to replace inotify, it s only a stub for now. Someone will have to write the code to actually act on the events and trigger the rescans/database updates. kqueue/kevent delivers a lot less information compared to inotify, which means there s a lot of work needed to track renames and moves. And I didn t feel like doing it. So, FreeBSD users: send patches! :)

I ve spent the last week packaging VMware Workstation 7.0.0 at work. Looking around on the net, I ve been unable to find anything helpful about packaging this new version, so it seems nobody s got around to packaging it yet. I ve asked our customer for its approval for releasing our packaging scripts to the community and got it, so here are our packaging scripts for this version, courtesy of EDF. See the instructions in debian/README.source for what has to be done to turn it into a full source package. The packaging is based on our previous 6.5.2 packaging, which was itself based (partially, at least) upon the Gento 6.5.2 ebuild. It uses a tweaked vmware-installer to install the products to debian/tmp, then makes use of the vmware-installer database to populate the packages. I think this method should work with any VMware product using vmware-installer 1.1. Packages have been built and tested on Etch and Lenny. Hope it helps! Bugs, comments, questions to the email address listed as Maintainer in debian/control, please :-)

Over the past weeks, a couple of contributors sent me fixes and new features for forked-daapd. Thanks to you all! The biggest change is the addition of TV shows metadata as found, for instance, in TV shows bought on the iTunes store. Together with the added support for FrontRow and QuickTime clients, this means forked-daapd is a lot more able at streaming video files than it ever was. Kudos to Ace Jones for his work! Note, however, that you ll need a patched version of ffmpeg to pick up the TV shows metadata from your MP4 files. At the time of writing, the patches have not landed into ffmpeg upstream yet, and it s a bit unclear when this will happen. Contact Ace for the patch and instructions, see the commits in the git tree for his email address. Git tree on Alioth: http://git.debian.org/?p=users/jblache/forked-daapd.git (git URIs on the page)

I ve just bought a Packard Bell OneTwo (M3700), a 600 Euros all-in-one computer with a 20 multipoint touch screen (there are bigger models with 23 touch screen, wifi and some other options). This machine will be used to run OpenBravoPOS, a free (libre) point of sale software. So far, I think this machine is just perfect for the job. Getting it to run smoothly under Linux is not a walk in the park, however. There are some quirks and some assembly is required, but once you re done (that takes a couple of hours at most once you ve got all the info, which you have if you re reading this) this machine is just great. It s fast, with a 2.1 GHz Pentium Dual-Core (T4300) CPU, 4 GB of RAM, an Intel GM45 GPU with up to 256 MB of shared RAM, gigabit networking, a fast 320 GB SATA disk and a combo DVD-drive (not a slot-in, too bad). The screen is nice, and the touchscreen is incredibly smooth, precise and sensitive. The sound is good, the webcam is great and it works out of the box, too! Update: added a note about the card reader. Before you go Enter the BIOS and bump the amount of memory allocated to the GPU to 256 MB. By default, the machine ships with only 64 MB allocated to the GPU, which is low and ridiculous considering it is equipped with 4 GB Installing Debian Forget about installing Lenny with debian-installer on this machine. The standard installer with its 2.6.26 kernel doesn t support the network interface properly. Upgraded installer images with 2.6.28 or 2.6.30 kernels end up locking the machine solid before the first installer screen. Your best friend: System Rescue CD. Your other best friend: debootstrap. Before rebooting, install the 2.6.30 kernel from backports.org. It works like a charm, even if the 2.6.30 on the upgraded installer locked up solid. Go figure :) While you re at it, install X from Testing. You need a recent enough version of the intel driver that will support the GM45 chip. Configuring X This is the first and the biggest quirk on this machine. The LCD is actually wired up to both the VGA and the LVDS outputs on the graphic card, and advertises different resolutions on both. The native resolution (1600 900 on this model) is only advertised on the LVDS output. While fiddling with X, it becomes obvious that the VGA output is used as the boot video device. If you disable the output in X with xrandr, you loose the text consoles. My un(?)educated guess is that this setup allowed them to use a standard desktop PC BIOS instead of using a more expensive laptop BIOS. I may be wrong, but that s pretty much the only thing that makes sense to me. Anyway. If you want X to work properly, you ll have to tell it to ignore the VGA output entirely.

Section "Device"
 Identifier  "Intel X4500"
 Option  "Monitor-LVDS"  "Panel on LVDS"
 Option  "Monitor-VGA"  "Panel on VGA"
EndSection
Section "Monitor"
 Identifier  "Panel on LVDS"
EndSection
Section "Monitor"
 Identifier  "Panel on VGA"
 # The LCD panel is wired up on both VGA and LVDS
 # Ignore the VGA output as far as X is concerned
 Option  "Ignore"  "True"
EndSection

If you don t tell X to ignore the VGA output, you ll end up with a mirror setup and your desktop will use the smallest size so as to fit on both monitors. It isn t pretty, it s plain silly and we want those 20 used fully, dammit! See the full xorg.conf. Touch screen The touch screen is an infrared multipoint touch screen from Quanta. No kernel driver is needed, only an input driver for X is required. Start by adding an udev rule like this one:

SUBSYSTEM=="usb", ATTRS idVendor =="0408", ATTRS idProduct =="3000", SYMLINK+="usb/quanta_touch"

The touch screen will now appear as /dev/usb/quanta_touch, which is more handy and stable than /dev/usb/hiddevN. Grab xf86-input-hidtouch from HidTouch Suite on SF.net, and apply this patch. The aim of the patch is to ignore anything but the first reported pressure point. The touch screen is a multipoint touch screen and as such can report 2 or 3 (not sure) pressure points at the same time. The driver can t handle that yet. The patch also fixes a bad comment and an API difference with newer X versions. Build and install the driver, then edit xorg.conf:

Section "InputDevice"
 Identifier  "Optical Touch Screen"
 Driver  "hidtouch"
 Option  "SendCoreEvents"  "true"
 Option  "ReportingMode"  "Raw"
 Option  "Device"  "/dev/usb/quanta_touch"
 Option  "PacketCount"  "13"
 Option  "OpcodePressure"  "852034"
 Option  "OpcodeX"  "65584"
 Option  "OpcodeY"  "65585"
 Option  "CalibrationModel"  "1"
 Option  "CornerTopLeftX"  "0"
 Option  "CornerTopLeftY"  "0"
 Option  "CornerTopRightX"  "1600"
 Option  "CornerTopRightY"  "0"
 Option  "CornerBottomLeftX"  "0"
 Option  "CornerBottomLeftY"  "900"
 Option  "CornerBottomRightX"  "1600"
 Option  "CornerBottomRightY"  "900"
 Option  "CornerScreenWidth"  "1600"
 Option  "CornerScreenHeight"  "900"
EndSection

There you are. Working touch screen! Credit: the above touch screen setup instructions, including the patch (which I reworked slightly ) were taken from this post on the Ubuntu-fr.org forum. The instructions cover the Packard Bell Viseo 200T touch screen, which is identical to what s used on the OneTwo. If you re looking for a 20 touch screen, go for it; at 200 Euros it s a good deal. Sound The Realtek ALC268 codec as used in the OneTwo isn t properly supported yet, however using model=acer-aspire works for the integrated speakers and the headphone jack. Line out and the integrated microphone do not work. Webcam The webcam is a UVC webcam and the image quality is stunning. I m seriously considering stealing that webcam to replace the iSight in my MacBook Pro. It works out of the box without any firmware. Quite a good surprise :) Flash card reader The integrated flash card reader also works out of the box, for the card formats supported by Linux.

Pommed v1.30 is a bug fix release fixing two small bugs:

• a crasher bug on PowerMac machines
• a bug in the sysfs backlight driver, mishandling brightness values with more than 3 digits

If you are running on a recent MacBook/MacBook Pro with a recent kernel, you ll probably want to upgrade to this release.

pommed v1.29 is a bugfix release, kind of. The fix is an architectural one related to the video mode switch feature. When pressing the video switch key, your graphical pommed client of choice checks which VT its X server is running on and whether this VT is the active one before executing your video mode switch script. To check that the VT is currently active, it is necessary to open one VT (we use the one our X server is running on) and perform an ioctl() call on it. Depending on your setup (login manager or startx, basically), your user will or will not have any right on the device node associated to the VT. Which means the VT state checking code would always fail in some setups. This is now fixed by moving that code into pommed itself, with a DBus method for the clients to call. You ll need to update both pommed and the clients for this to work, for obvious reasons.

You want to revitalize a dying, inactive free software project. How do you proceed?

1. You write code, contribute, get involved in the community, get in touch with the previous developer(s) to try and join the team or take over the project. Failing that, you fork the project, because this is how free software works after all. Then, once you ve got something to show, you start talking about it;
2. You set up a new forum, brag about it on the old one, arrange with the previous lead developer to make sure you can use the name and logo, then open a twitter account so users can follow the new forum s setup process minute by minute.

There s this saying about opensource/free software that says the logo and about box are the very first (and only) things that work in new/young projects (and sometimes that s also true for more mature projects, as we all come to know). Choice 2 above is the About Box 2.0. Unfortunately, that s the way a handful of people choose to revitalize mt-daapd/Firefly Media Server. Of course, not one among them can code or has actually got a clue about the current codebase. FAIL of epic proportions. Facepalm.

pommed v1.28 is a minor update adding support for the MacBookPro5,3.

did FAI switch to that stinking pile of shit known as live-initramfs? Things that were possible before aren t possible anymore due to the extreme brokenness of live-initramfs. Nothing that can t be fixed by some heavy-handed patching here and there, but what a waste of time. Not happy. Hammer time.

Joerg, The patch you submitted has 0 chance of getting applied, and you know it. It s nothing more than a bad joke. The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.

Don t like HAL? X.org now forces it upon you via xserver-xorg. #515214, currently wishlist/wontfix.

From the Bits from the Debian Installer team mail to d-d-a:

It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn t make the process very easy, changing the VCS we use is currently not an option we prefer.

SVN, branching, d-i. There s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix. That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it s off the table, second because some things in this mail are just wrong. Oh well. No d-i for me, I guess, then.

I ve just released a maintenance release of pommed. Nothing new under the sun in this one:

• support for the new mini external keyboard,
• the keyboard backlight idle timer now only takes keystrokes on the built-in keyboard into account,
• move away from using /dev/mem to access PCI memory, use sysfs resource files instead.

There are a couple of ideas floating around, we ll see if any one of those lands into a future release.

So, Kodak announced the availability of Linux drivers for some of its scanners, together with a frontend application. While the effort is laudable, they re not quite there yet. Let s have a look. First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren t OpenSource, let alone Free Software. They re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2. Now let s look at what Kodak offers in its drivers packages. I ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series. The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script. One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren t there, I haven t asked for the sources, don t plan on doing so, and am not implying anything regarding license compliance whatsoever. I ll note that I haven t seen any written offer for the sources, though, be it in the archive (there s not even a README in there) or on the website. So, although Ubuntu is listed as supported, we can say that no Debian packages are provided. The setup script actually relies on alien to convert them if it thinks it s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal. The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak. It looks like the SANE backend is only a bridge to Kodak s TWAIN data source, so you d actually need the whole stack to use it. All in all, Kodak does no better, I d even venture to say it does worse, than Epson (Avasys). At least part of Epson s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones. I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren t that great (I think the RPM packages even lack dependency information, based on what I ve read in the setup script, though I haven t checked). What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn t a backend so to speak, and even if it was OpenSource it d still rely on the rest of the TWAIN software stack. So, in a nutshell, while I m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages. I was, of course, investigating the drivers to possibly package them for Debian; as you ve probably understood, it s not possible, both technically and legally. And I kept a little gem from the setup script for the end:

# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
    ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi

As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.

I ve been doing some code lately, fixing things here and there, and over the last few days gave mt-daapd some attention. First, I was reported a segfault of mt-daapd when reloading web pages too fast. Surprisingly, it turned out to be a stupid omission in a simple routine and it is hard to hit without disabling the cache in the browser. Now, I just fixed something that s been bugging me for a while: mt-daapd did not handle Avahi daemon restarts, leading to mt-daapd becoming invisible to clients relying on mDNS until you restarted it. And, wow, that went a bit further than expected. As I expected, the simple piece of code needed to handle that wasn t there. But still it did not work, as it turns out the event loop for the Avahi polling wasn t being run. Replace stupid code reinventing the wheel by the Avahi-provided wheel and there, it works. But not when run as a daemon (aka foreground only). Well yes, starting the thread before daemonizing isn t going to work well, so fix that. EPIC WIN \o/ As mt-daapd s upstream is not active anymore I m accumulating fixes for mt-daapd in the Debian package, to the point I m starting to consider setting up a git repository somewhere with those fixes and possibly some more code rework if I feel like it.

I ve migrated pommed to git yesterday. The public URLs for the git repository are: git://git.debian.org/git/pommed/pommed.git
http://git.debian.org/git/pommed/pommed.git The SVN repository will disappear shortly.

How not to start your day, from the all-hardware-sucks department. For years, I ve been struggling to keep my machines quiet. I ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:

• big, heavy, quiet case from Chieftec (with room for 8 HDD and their own dedicated 90mm fans (up to 3) and room for 2 120mm case fans);
• ber-engineered fans from Noctua (finally some guys took a shot at engineering fans, happiness \o/);
• fanless (except for the emergency fan) PSU from Antec (Phantom 500).

I ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality. So, wake up today, do random things, grab my TomTom, unplug it from the workstation it s sucking its power from, do things, plug it back in the USB port so it won t draw its battery. This is how it went:

• plug TomTom into USB port;
• notice the LED is blinking, and it should not;
• erupt a mental WTF? and simultaneously hear *clac* *pffzziiouuuu*;
• unplug TomTom;
• replug TomTom, notice the LED is blinking again;
• look at the machine, notice it s gone down;
• check the PSU and erupt a verbal WTF?! noticing the LED on the PSU is not lit.

Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU. Grab the tools, crack the PSU open. Notice bulging and leaking capacitors. Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula. (If you need a reference, google for singing capacitors . Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.) A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date. Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running. Then I ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.